Skip to content

Add ms suffix support to DurationTag - #125

Open
BehrRiley wants to merge 4 commits into
DenizenScript:masterfrom
BehrRiley:feature/millisecond-support
Open

Add ms suffix support to DurationTag#125
BehrRiley wants to merge 4 commits into
DenizenScript:masterfrom
BehrRiley:feature/millisecond-support

Conversation

@BehrRiley

@BehrRiley BehrRiley commented Aug 25, 2026

Copy link
Copy Markdown

Summary

this pull request adds millisecond suffix support to the DurationTag, allowing scripters to define rapid durations nicely (eg: <duration[3ms]>). this removes the need to divide define milliseconds

Problem

when defining durations, we previously lacked a native millisecond suffix; and when checking for suffixes, there was a structural issue where ms strings were being trimmed by only one character which would fail to parse right. if placed wrongly, "3ms".endsWith("s") would trigger as seconds instead. this fixes the length-check to strip two characters for ms, scales the numeric value by 0.001 to maintain consistency with our existing multiplier standard, and uses the ms branch before seconds to avoid problems

Testing

  • Tested on the latest supported patch-versions
  • Verified integer and decimal values parse correctly (eg, 500ms, 250.5ms)
  • Verified conversions correctly parse inside DurationTag.in_seconds
    used various examples:
  • /ex -q narrate "1ms = <duration[1ms].in_milliseconds>ms"
  • /ex -q narrate "500ms = <duration[500ms].in_milliseconds>ms"
  • /ex -q narrate "1000ms = <duration[1000ms].in_milliseconds>ms"
  • /ex -q narrate "500ms = <duration[500ms].in_seconds>s"
  • /ex -q narrate "250.5ms = <duration[250.5ms].in_milliseconds>ms"

here's a startup log referencing this test with tags parsed for verification:
https://paste.denizenscript.com/View/141404

a working build of my latest successful build which has no errors can be built with this branch or found at:
https://files.behr.dev/file-share/Denizen-1.3.3-bUnknown-CUSTOM-ms-durationtag.jar

return new DurationTag(numVal * 0.05);
}
else if (string.endsWith("ms")) {
return new DurationTag(numVal / 1000.0);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should stick with the conversion pattern that already exists ("* 0.001" rather than "/ 1000.0").

else if (string.endsWith("t")) {
return new DurationTag(numVal * 0.05);
}
else if (string.endsWith("ms")) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is wrong; this branch cannot ever be hit

Comment on lines +110 to +115
if (quickMap == null) {
val.getMap();
val.string = null;
modified = true;
continue;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this isn't related to the same issue, it should be in a separate PR.

@BehrRiley
BehrRiley force-pushed the feature/millisecond-support branch from b24c0a6 to 664acd2 Compare September 5, 2026 01:25
}
}
String numericString = Character.isDigit(string.charAt(string.length() - 1)) ? string : string.substring(0, string.length() - 1);
String numericString = Character.isDigit(string.charAt(string.length() - 1)) ? string : string.substring(0, string.endsWith("ms") ? string.length() - 2 : string.length() - 1);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(minor) tern contains the same string.length() factor on both sides, can be simplified

@mcmonkey4eva

Copy link
Copy Markdown
Member

There's a lot of secondary ramifications. For example, <duration[1ms].add[2ms]> will NOT return 3ms it will just break (most code is written to assume tick as the smallest valid unit), or .formatted will misformat ms values. For this PR to be stable, you'll have to hunt down all the secondary effects this will have.

@BehrRiley

Copy link
Copy Markdown
Author

I made sure to as thoroughly test these as I could;
latest.log: https://paste.denizenscript.com/View/141483
script: https://paste.denizenscript.com/View/141484

// -->
tagProcessor.registerStaticTag(DurationTag.class, DurationTag.class, "sub", (attribute, object, secondVal) -> {
return new DurationTag(object.getTicks() - secondVal.getTicks());
return new DurationTag(java.math.BigDecimal.valueOf(object.seconds).subtract(java.math.BigDecimal.valueOf(secondVal.seconds)).doubleValue());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this... does anything of value with BigDecimal?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

before this commit, two of my close-edge tags parsed as 1.000000000001ms or something crazy; I've lost the log since


public RepeatingSchedulable(Runnable runnable, float fireRate) {
run = runnable;
if (fireRate > 0 && fireRate < 0.05f) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is very questionable and probably wrong

@BehrRiley BehrRiley Sep 5, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'll work on this; i expected if somebody asks RepeatingSchedulable to repeat faster than one tick that it should by default change their requested interval to one tick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants